home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000579_timbl@www3.cern.ch _Mon Jan 18 13:49:11 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  6KB
  1. Return-Path: <timbl@www3.cern.ch>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA09210; Mon, 18 Jan 93 13:49:11 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA13681; Mon, 18 Jan 1993 14:04:31 +0100
  6. Received: by www3.cern.ch (NX5.67c/NX3.0S)
  7.     id AA02388; Mon, 18 Jan 93 14:03:35 +0100
  8. Date: Mon, 18 Jan 93 14:03:35 +0100
  9. From: Tim Berners-Lee <timbl@www3.cern.ch>
  10. Message-Id: <9301181303.AA02388@www3.cern.ch>
  11. Received: by NeXT.Mailer (1.87.1)
  12. Received: by NeXT Mailer (1.87.1)
  13. To: www-talk@nxoc01.cern.ch
  14. Subject: Re: Usenet news and WWW
  15. Reply-To: timbl@nxoc01.cern.ch
  16.  
  17.  
  18. > Date: Tue, 12 Jan 93 0:06:00 CST
  19. > From: Karl Lehenbauer <karl@one.neosoft.com>
  20. >
  21. > Many of the issues that people seem to be grappling with are  
  22. already
  23. > handled by news.
  24.  
  25. Yes ... but on the other hand there are things which are already  
  26. handled by 
  27.  
  28. > For example, we are talking about caching nodes.  News has highly  
  29. evolved
  30. > caching capabilities -- I mean, caching is what it is all about --  
  31. both for 
  32.  
  33. > TCP/IP and UUCP-based links.
  34.  
  35. I agree.  There are some snags with nes, though, for the ultimate  
  36. retrieval tool. One trouble is, news caches documents very simply.  
  37. The distribution scheme is a flood broadcast.  This is  OK for real  
  38. news (shortlived articles), although many sites sag under the load of  
  39. a lot of stuff they never read.  There are strict limit on what  
  40. anyone posts because of the incredible worldwide total system load  
  41. and disk space usage per message.  There is no well-defined algorithm  
  42. for picking up archived news.  The message Id of an article is not  
  43. enough: you need to know at least one of its newsgroups, its date,  
  44. and be able to deduce the archibe node name and the organisation of  
  45. the archive.
  46.  
  47. The conventions of posing FAQ lists and other "periodic postings" are  
  48. in fact an abuse of the prototcol, and would be better served by a  
  49. retrieval protocol rather than a broadcast protocol.
  50.  
  51. I know that the NNTP WG is looking at this sort of area, and maybe we  
  52. should all get together.
  53.  
  54. In a nutshell, if you take all the data everywhere available online  
  55. and put it into news, the news system will die. The use of newsgroup  
  56. names and lists negotiated by system managers to control what  
  57. documents are visible and cached where is too crude, too inflexible  
  58. -- it doesn't scale well.  The caching has to be automatic.
  59.  
  60. All this said, obvioulsy news and retrieval are coming togather,  
  61. which is why we have tried to look for analogies (see previous  
  62. messages to this list) between news articles and grousp to hypertext  
  63. documents and lists at all times.
  64.  
  65. > Someone mentioned the issue of caching and node names, apparently
  66. > node names would have to be rewritten by the cacher or need to be  
  67. made
  68. > machine-independent in some way (?).
  69.  
  70. Don't worry about that.. I think you are referring to a discussion of  
  71. complete vs. partial UILs.  Let's keep that apart...
  72.  
  73. > Article IDs are guaranteed unique
  74. > and are server-independent.  The mechanism for translating article
  75. > IDs to filenames is fast and pretty highly evolved.
  76. > 
  77.  
  78. > Oh, ugh, "Supercedes:" doesn't cut it unless the article  
  79. superceding
  80. > the old one replaces its article ID, which would probably be Bad.
  81.  
  82. Certainly there is a  case for having the "current" version of an  
  83. article and a given "fixed" version of an article each explicitly  
  84. addressable. See  
  85. http://info.cern.ch/hypertext/WWW/DesignIssues/Versioning.html
  86. and linked things for an old discussion of these issues.
  87.  
  88. > Expiration dates can be set with "Expires:",
  89.  
  90. Exactly.  If you read the provisional HTTP2 spec there is
  91. an explicit link to rfc850 under "Expires". (See
  92. /hypertext/WWW/Protocols/HTTP/Object_Headers.html#z5)
  93.  
  94. >  and sites that 
  95.  
  96. > archive certain groups already do special things on  
  97. "Archive-Name:".
  98.  
  99.  
  100. Really?  Tell me more.  Is that in an RFC somewhere?
  101. reference? Example?
  102.  
  103. > Plus news is already ultra-portable.
  104. > 
  105.  
  106. > Is the brief-connection-per-document approach of HTTP still  
  107. necessary
  108. > when the data is widely replicated?
  109.  
  110. As I said above, the mass of data will not be widely replicated.
  111. You don't want a copy of all the data in the phone book, you just  
  112. want access to it, plus a cache (which you may currently keep in you  
  113. diary).  When you're talking about all the phone book sin the world,  
  114. this is still more the case!
  115.  
  116. So theer will in the end be a directory system not unlike X.500 which  
  117. will allow you to find who has the nearest copy of a document you  
  118. want, in a fairly sophisticated way. And you will pick up up from  
  119. that place.  Then you will click again and pick up a reference from  
  120. somewhere else.
  121.  
  122. An important feature of HTTP is that the document is returned with  
  123. the minimum number of round trips. (Sorry for all the people who have  
  124. heard this before).  Conection-oriented protocols like WAIS and NNTP  
  125. have an introductory dialogue which slows down the first fetch by n*  
  126. the distance/speed of light.
  127.  
  128. We probably need horses for courses -- there is nothing wrong with  
  129. keeping a few protcols around optimised for different access  
  130. profiles.
  131.  
  132. (BTW I think there is a need for a point-point low bandwidth protocol  
  133. designed for beating the hell out of a phone line. One that will keep  
  134. the phone line occpied in a very inteligent way with look-ahaed  
  135. fetches of related documents and lists or parts of them so that a  
  136. home user with a big disk can explore with optimised ease when he is  
  137. paying by the minute. Another good student project)
  138.  
  139. > It would be painful to go reap all the references that
  140. > point to expired articles, although if a user traversed to an  
  141. expired
  142. > article, perhaps it could be pulled off of tape or an NNTP  
  143. superserver 
  144.  
  145. > somewhere.
  146. > 
  147.  
  148. > Clearly the authors of WWW think news is important because WWW has 
  149.  
  150. > nice capabilities for accessing NNTP servers.  What, then, is the 
  151.  
  152. > motivation for HTTP as opposed to, say, using news with HTML  
  153. article 
  154.  
  155. > bodies?
  156.  
  157. I hope I've showed that broadcast data can't cover the NIR world. But  
  158. I also hope that we can allow the models to converge and create a  
  159. supermodel which encompases them.  This is the end goal of HTTP2 or  
  160. should we call it NNTP3.
  161.  
  162.  
  163.